Asset Creation Process
Sitemap Asset Creation Process * See also Player_Created_Asset_Collaboration_System * See also Game_Editing_Tools * See also Types_of_assets * See also Player_Creation_Contests * See also Player Created Assets --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Help Us Build Rapture' - Company getting Players to Assist in some of the Initial Pre-game Starting Asset Data : ''' '''Development Phase : * Mostly Company work to establish the Working Mechanisms. * Basic templates for Asset types complete. Behavior scripts developed for NPCs and Splicers. * Game Engine operational (Server and Client working as designed) . * Developer testing of proper functionality made and confirmed (minor problems identified for further fixes) * Initial Assets (all flavors) tested to prove they work. Skeletons for Mission/Quests and more complicated Assets test. * Company gets ALL the Creation Tools] beaten into shape (Best to find the deficiencies early) (Player-used tools need a bit more polish and 'bomb/idiot-proofing' than Company developer-used tools would require). * Proper documentation, tutorials, and examples written for Player use (Some Players may be selected for Documentation review). Lore and Canon guidelines made ready for Players. * Collaboration Repository (Web-based) is operational and IDE tools work. Forums and other communication systems operational. * Standard NPC interactions (Shopkeepers/CityOfficials/Murderous Splicers) built as Templates and tested for adequate behavior/operation ('Personality' details will be added later). * Conversion Tools/process for 'Legacy' BS1/BS2+MP/DLC content proofed. * Seed Data for game World is planned (what parts will initial parts will exist and what will be left for auto-generation later). Alpha Phase (Proving the collaboration system process works) : * Alpha testers (players selected - prefer those with abilities to test/identify problems ) * At this point the company developers have sufficient parts of the client/server/tools working that players can start trying to use them to do the creation process and make them work in the game environment. * Restricted Player use to functional testing (not really creating assets for the game yet). Players should be able to create assets and have them applied to a test server where it would operate correctly. Sandbox World setup as a stage to test the creations on. * Documentation is proofed to show it will be sufficient for Player's need. Additions added via the Community process. * Work the bugs out of the whole Collaboration process - Players use the process to demonstrate all the features work (setting up projects, creation, submitting, vetting, adding to active game system). * Alot of developer debugging still done at this point. Players understanding this is a system still under development and they should look for and report problems. * Working with the more complex asset aspects (scripting, prop templates, NPC data sets/templates, Quest Templates) which would exercise the Server code and Client mechanisms quite a bit. More sample assets built just to prove the various parts of the system work with them. Generic test assets can be used later to retest the system after fixes have been made. More detailed combination testing of Game Mechanics. * Many game mechanics/other general problems would turn up and be fixed (better before large numbers of real assets need to be reworked - due to any fundamental changes). * Test Servers will (as usual) turn-over frequently as major fixes are put in. * Preliminary REAL game assets extracted from 'Legacy' tested by players to prove that extraction process works. (deficiencies fixed) and to act as a 'stage' for more complex testing (quests/auto-generation/etc..). * Placeholder 'generic' objects defined to use in combination testing -- where you can setup a scene with all needed assets even though they don't have all the final detail yet (ie- a generic human figure that can do animations and reacts with most of the default behaviors/reactions). Generic containers, vehicles, building sections, weapons, machine components, etc... * Alot of planning for Beta phase with priorities for what assets need to get built up. * Seed data defined and existing City layout planned. Beta Phase (build the initial game assets and test functionality in game environment) : * Creation tools are ready for players * Beta testers (players selected - general creation skills) - Opening up to larger number of players to help start building the initial start game assets. * Build up the Collaboration community - creators, advisers, vettors, collaborators (most probably will be bugs to be worked out and for the many players to 'train' to use the collaboration mechanism). * Develop Collaboration experts - members of the player community who will be responsible for the 'peer review' (and get the Company personnel who will do the Official Inspections trained up also) * Test Servers need to be fairly stable - but still likely to face major 'fix' and improvement changes. * Company employees start tearing apart the existing 'Legacy' BS1/BS2/MP/DLC data to for conversion to 'objects' and farming out to players who will do the rework into MMORPG data. ** Work Slicing-up existing buildings (BS1/BS2 stuff) up and converting them to the new modular system. ** Props, lots of prop objects (extract from the 'levels' data). ** Create the object state (new damaged/grungy...) variations -- the textures/meshs for all the prop objects (and sub components) ** Rework human figures and add more animations (citizens don't physicall act like splices so much) ** Citizen NPC Behaviors (living their lives - or at least appearing to) built using generic templates. * When the REAL assets are built they can then be placed in a growing World (which allows further real additions using those assets). Placeholders can be replaced as the assets are built. ** Build initial sets of quests (even 'missions' of typical MMORPG quality would be a start). ** Testing the economy system and all the fabrication/construction/shop/'Team' interactions. ** Verify all the player 'helper' interfaces ** Exercise the Auto-Generation (both the small 'room' type variations but also the city expansion mechanism) as REAL auto-generation templates are built to match the Seed Data requirements. * Continue until the Existing City layout and dependent assets are ready. Gamma Phase '''(mass testing of game - normal 'beta' test) : * Most initial game World data is ready (missing bits will be built and added if needed) * Servers loaded with start/release data state. * Extended Server loading/stability/stress tests done * Large numbers of players running real game play activities (playing the game) on the Test Servers. * Full game world operation to test all aspects (do test of process of patching new assets). * Late fixes (if any). * Collaboration Players get head start on new asset submissions (new assets submitted when game is operational). More extractions from old data as well as new creations. * All Servers readied for Game-Start. * Planning for first post-start game expansions being made (more props/locations/Quests...) '''Game-Start : * Rapture Rises Again... * Company has saved 'oodles of money' making the game and have a modular/auto-generation/collaboration system that can be used for creating additional MMORPG games (and much of it usable for Solo games as well). * Everyone needs to keep an eye out for loopholes and deficiencies in the game (Players are creative and will do things testers never think of). Things that can cause major unbalancing of the game have to be handled immediately. * Company does some work on New Content, also guides 'Player Created Asset' Collaboration to 'flesh out' more game play. * Lots and lots of new PLAYER CREATED game content starts pouring in to expand the game. * Game industry says 'Whoa, Wish we thought of That !!! ' .... * Profit ... ---- ---- ---- Required Components of the Collaboration/Publishing/Vetting System : * IDE (Integrated Development Environment) the basic tool used for player asset development/creation. * Asset Creation tools to create/modify ALL assets with all data -- in correct game formats. Importers for external formats used by third party tools. * System to make requests for specific assets needed for the game (either variations or to fill a specific game function) * Guidance from company/player experts as to what object types should have priority to fill gaps in available types (or for consistency of coverage -- do we need a twentieth new 'chair' when there is only 2 types of 'desk' and one 'couch' ??) Extra incentives may be needed to help fill 'gaps'. * Forums for discussions between players on the entire collaboration subject (including testing procedures) - some people are good at thinking up good ideas and others making the ideas into something useful. Easy/effective communications are central to success of the whole mechanism. * Repository of existing game assets/templates are to be available to use as starting points for creating similar assets. * Easier than starting from scratch (saves alot of work) This facilitates Upgrading of existing assets. * All accepted assets are open for inspection and cloning (there is no locking-down, if someone is capable of making significant improvements then that is good for the game). --- --- --- Process Security : * Certain Identities may be established by a proper certificate authentication (via IDE used for control of all offcial submissions) that access the final decisions (ie- the go-ahead to pass an asset to the company...) * No existing assets can ever be lost/damaged by defective/disruptive submissions (the usual feature of a source control system) * Forums would have the usual login required for postings, to control Spambots and disruptions caused by the usual mentally deficient. Moderators would keep the forums cleaned of irrelevant posts. * Company would be required to supply sufficient secure backed up server resources for ALL the asset data repositories. * Secondary Collaboration: Some groups of player might feel that they can do a better process collaborating and could set up their own communities to confer/design/create/vet assets. * ALL Assets still have to go thru the offical process (peer review and company acceptance) * Sub-communities with goals of 'localization' (translating to different languages) would be likely. Such tasks might be quite significant (think of all the text translations for every NPC quip and statement and quest story, let alone any voice recording and sign translation) --- --- --- Documentation of All Asset Template Definitions (game mechanics related) *Must contain all attributes needed to define this assets use/function/behavior. *Examples of template use help alot with all the many attribute even ordinary objects ('the chair') have (saves time to know which ones to leave 'default'). --- --- --- Mechanism to Assist in Passing Partial Works Between 'Creators'. * Many assets that result in a object instance are actually made up of many simpler component assets. * The whole cannot be activated on any server until all the required pieces are present (they have to be grouped together on one IDE so that the automated tests and packaging can be done correctly.. * All IDE assets are exportable and the data files are transportable to an IDE on another machine. * A good Search mechanism to find similar Assets or linked for documentation for asset proposals and for any in-progress asset projects (so user can see if someone else already working on the same idea). * Post and Search mechanism for 'Looking for assistance' by players who need collaboration to finish their Asset. * A Method for Feature Request (to game company) for game mechanics addition/bug fix ** With proper description and explanations included and with specific details of what the change will affect ** Backwards compatibility is a key requirement for all game mechanics changes (to minimize rework existing `assets). * System of Escalating roles privileges for successful creators. ** After a creator has proven ability on simpler tasks then more complicated assets are allowed to be submitted. (This helps cut back on poorly designed/executed Assets that WILL get rejected and thus waste other peoples time and effort). Users who continue to submit garbage need to be identified so they can be filtered/blocked/marked so as to not waste other players time/effort. * 'Dif' Tools to highlite the changed part of asset data from the previous version - helps reviewers zero in on what needs to be tested/inspected (if assume the old version worked correctly, any changes would be source of defects). * Proper Attribution of Credit for the work done to the Player who did it (design/creating/vetting/bugs/upgrades) ** Somehow enumerate 'effort' if multiple collaborators (see 'score' below') were involved. ** Often there are multiple sub-assets done by different creators or the same asset is passed thru several authors (ex- basic creation and then polishing). * IDE for player (client of creation system) to handle the transactions facilitating the collaboration process : ** Talks to Server collaboration/publishing system (automates routine actions, preferences, etc..) ** Lists the users ongoing projects (selection of current project) ** Lists states/schedules of the users project(s) (see the process details below) ** Access to common tools (various editors /code inspection/test tools/ validation tools/simulators/etc..) ** Keeps track of checklist for submission process (including interactions with community reviews) ** Logging of project status changes and feedback ** Asset Search front-end (including search wizard taxonomy helper) ** Notifications (mail tie-in) system tracking of project(s) progress ** Assists with Downloads of various info (assets/templates/documentation) ** Paperwork fill-in helpers (for various required descriptions/documentations/notes) ** Collaboration Assistance tool (posting to seek/accept/coordinate collaborators - sub-projects). Various parallel notifications to the people working on a project. ** Integrated Debug Tools with Ability to replay recorded 'bug evidence' of specific cases. Recreation with appropriate simulation tools. ** Posting mechanism for the Pre-submission/Peer Review phases (can run available validation tests and packaging) ** Links/Wikis to Web-based information - Forums/FAQs/Documentation/Demonstration sites ** Largely automatic ('push of a button') Backup of IDE data (local and/or to server) -- nothing is worse than losing days worth of work when you computer craps-out. ** Note - many of these things could be done manually but as time goes on (hopefully alot would be spotted in the pre-release activities) tools will be made more convenient and routine/frequently used mechanisms streamlined/auto-assisted. Ease-of-use is important to a system use by a wide audience, who don't want to fight with the interfaces everytime they want to get something done. ** Quickload feature for test servers to allow the IDE to upload new test assets onto a test server (and from there parts onto a Client) so that they can be tested in situ. More complicated assets require groups of other assets to interact with (including NPCs and Player avatars) so an 'arena' style instancing system would be done. * Inspector (Privileged User) additional IDE features ** Listings of pending 'inspections' and their status (incoming list) ** 'Expert' commenting/markup tools (can record 'bug' evidence for problems found) ** Runs various inspection tools/viewers/editors/simulators/commentators etc... The tools are rigged up to run the data packaged by the author with the least amount of effort and similarly the review is packaged and sent back. ** Votings ??? (some Asset reviews are consensus) ** Review checklists (inspection tasks are tracked for each reviewed asset project) ** Messaging system for consultation with other 'Inspectors' (use to send partials to other experts for their opinions) * Test Servers with the developer test Tools Enabled for common users. ** Allow players to force situations they want to test (allow them to run Scene Definition Scripts (Tools to help with this) to set up quite complicated pre-defined situations). ** Debug Info from Objects and being able to view/inspect internal state. ** Full Server code is probably too complicated to be run on a Players machine (besides being proprietary) -- So 'test Servers' need to be available quite early on to allow players to test their more complicated asset creations (ones with Game Mechanics interactions in the scripts and intra-NPC behaviors). ** Since the 'Instance Bubble' mechanism exists as a normal feature of the Server Architecture, many small independent 'SandBox bubble instances can be used by players for their testing. Clonable 'typical' scenes would be available to streamline context/situational testing. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - 'Object Instances Capable Of Being Created 'On-The-Fly' (via auto-generated using the template assets) :' * The 'parameters' come from the context the object is being placed in and also are specified from the setup Script that is defining all the Objects that are to be placed in a 'scene'. * All details are resolved/finalized/fully-built so the object can be used (activated) in the game. * NPC/Splicer object instances built to appropriately fit a specific situation (the Player just walked in on) * Prop instance 'dumb' object that is used to populate the game world as a detail. * Quest Instance (product of a Quest Scenario Template being run): ** Represents an active quest associated with a player (its data will control the quest state, specific details) ** Quest Control Script was defined/parameters-set to customize it to the current situation --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - Collaboration Process Aspects: * Open submission of Upgraded/Improved Objects (any existing asset is available for potential upgrading by player swho think they can do better) * Open submission of totally new assets (something that doesn't exist or is significantly different) * The Collaboration Process is setup to minimize rework (immediate rejection of defects instead of wasting further time on something that will have to be redone again later anyway). * Creation is to be made as simple as possible for players (with the least skill necessary). * A Collaboration Process is set up to make use of players for vetting Assets before it goes to Game Company personnel (much of the process would have well specified acceptance criteria, with early tests by automated methods to cull bad submittals) * Requires EULA/whatever that boilerplates 'Player Created Assets' are FULL property of the company once submitted. ** Covering final right of company to accept/use an asset in the game worlds ** Usual warnings about players submitting incorrect/inappropriate/plagiarize/copyright-infringing ** Company will remove any bad/invalid assets that slip past vetting process * Requires system where NO submitted info is ever lost. Proper backup and versioning will be done. Incremental work/improvements of assets can cumulatively achieve optimal assets. * Dependency on tools specific to game data format and importation for formats from outside tools (standard formats). --- --- --- The Game Company Will Supply Many Significant Tools to Help Streamline Creation Process : * 'Mod' tools are one of the extra costs that often make a good 'Player Created Asset' system prohibitive. Open Source tools (and modular subtools) will be used when possible (and cut that expense). * Tutorials for common tool usage are very helpful (an understatement). Some things still take skill (like 3D shape editing) and others are just mysterious until player shown how easy is to do. * BioShock Rapture Official Lore/Canon specifications/guidelines - required for subject content for assets being created. Needs to be well detailed to help minimize submission of inappropriate assets. Updated/corrected as issues not covered come up. * Technical details for game mechanics interfaces (for scripting) would be specified properly to allow players to code effectively, as well as with mechanical correctness. Especially important for existing 'Templates' that perform things that DONT need to be coded again. * FOR EVERYTHING INVOLVED ---> Forums to address definitions/misunderstandings/corrections to Canon/Lore doc. With standard User registration security for access to cut down spammers etc.. Moderators to keep posting within subject * Catalog/DB/Search taxonomy system for defining asset flavors/templates -- for easy reference of available assets to facilitate upgrading or variants -- using existing assets as a starting point. * Need tools that do a 'dif' to highlight changes from a previous version, to make it easy to see what has been changed . Tool for reviewers and inspectors (for vetting to concentrate effort). * Contests and Challenges can be offered to encourage development of 'needed' assets (to balance out work done on more 'popular' assets and to encourage more complicated submissions). Many player creations require supporting assets to 'round out'a proper game experience. - ie- a new boss with lair/location/props/etc... would be good to have several quest/mission scenarios added to interact with the 'Boss'. Asset Creators would be 'guided' into generating these associated details. --- --- --- Goal - Minimize Asset Memory Requirements and Processing time for Behaviors : ''' * Possible/preferred reuse of existing attributes/data (textures/sounds/scripts etc..) * Tutorials showing how to minimize resource (memory/CPU/Rendering) use for final objects - compacting textures, AI optimizations, etc.. * These things have a major impact in a game that has so many interactive objects around the players) * Will have FAQs and Examples of efficiency improvements of all kinds, showing common mistakes, best practices, etc... * Guidelines for how much resources (CPU/Memory/Rendering) an asset should consume (there are maximums that the automated tools will check for) * Standard limits might be waived if no way is found to otherwise fit a 'superior' asset. * Author ratings might be (re)awarded for assets that come in well under resource limits and with the asset still being acceptable (this might be hard to judge). * Automatic tools to measure and report resource usage (data counting easy, rendering load test a little more complex) * Techniques for minimizing Resource use should be documented and recommended to authors. * Templates should be written well optimized as they get reused over and over (and add any inefficiency to object created with them). Same should go for all documented Examples that should always exhibit 'best practices'. --- --- --- '''Proper Handling of Major 'Game Mechanics' Changes (fundamental way the game code works) : * ANY Changes to game mechanics MUST be well documented and announced/made available to community WELL in advance (and communications posted as to impact and possible effects on existing Assets). * Library/docs pre-distributions of pending changes would be made available to authors, etc... * Changes may cause rework of existing assets (automated retesting can detect catastrophic effects of any change) * Prefer to minimize this and get most fixing/extending done in PreRelease period. Often such changes will directly effect - Templates internally use changes (not requiring rewriting objects that use them). * Mass testing of all game object types can be done using the automatic tests (as a start) with minimum human work. * Most new object attributes wont cause issues, splitting/specializing attributes CAN cause many issues. Default behavior attributes should make least difference in behaviors. Author of assets should be notified to allow them to retest their own. * Game mechanics must be versioned so that new changes can be pretested by the collaboration community. Test Servers with the new version levels would be deployed. Client simulators would run (version patched executable and assets). * Authors with asset projects affected by proposed changes may be automatically identified (traced by the library/templates their assets make use of) and notified to hold work on their assets until all the Game mechanics changes are tested and accepted. * Players can submit defect reports against changes to game mechanics (perhaps a mechanism can flag all things that make use of a particular feature that has had changes, and certainly any AutoTest mechanisms can be run) * Completeness - does it accomplish what was defined to do (a missing endcase, etc..) * Not being backward-compatible - it will break existing assets (when it should be designed not to) * Design-error - serious missing part of design or execution does not match the original change request * Breaks the system - defective. Detected either by automatic or manual regression tests. Asset scripting is NEVER supposed to disrupt the Servers, but that is achieved by the Server code be designed correctly. --- --- --- --- --- . .